home *** CD-ROM | disk | FTP | other *** search
Text File | 1992-07-15 | 2.4 KB | 59 lines | [TEXT/GEOL] |
- Apple II
- Technical Notes
- _____________________________________________________________________________
- Developer Technical Support
- Apple IIgs
- #14: Standard File Screwiness
-
- Revised by: Dave Lyons May 1992
- Written by: Guillermo Ortiz, Matt Deatherage, & Dave Lyons June 1987
-
- This Technical Note describes known anomalies in Standard File.
-
- CHANGES SINCE DECEMBER 1991: Updated for System 6.0. Problems with the
- infinite loop and SFMultiGet2 reply record are fixed.
- _____________________________________________________________________________
-
-
- PREFIX CHECK IS CASE SENSITIVE
-
- When you advance to the next volume using Command-Tab (or just Tab, before
- 6.0), Standard File checks your prefix against the name of the volume now in
- the same device you were just using, to see if you switched disks (this is
- possible on a 5.25 drive, for example). If the name doesn't match, you stay
- at the same device.
-
- Unfortunately, the comparison in 6.0 and earlier is case sensitive. If you
- have a volume called "MyDisk" and prefix zero is set to ":MYDISK", advancing
- to the next volume doesn't get you anywhere the first time (but the prefix
- changes from ":MYDISK" to ":MyDisk").
-
- The following two problems are fixed in System 6.0:
-
- INFINITE LOOP WITH EMPTY PREFIXES
-
- In System Software versions 5.0 through 5.0.4, all Standard File dialogs can
- hang if both prefixes 0 and 8 are empty (GS/OS uses prefix 8 to expand partial
- pathnames if prefix 0 is empty).
-
- If this affects your software, use GetPrefix to check for empty prefixes
- before calling Standard File. If 0 and 8 are both empty, set prefix 0 to "*:"
- (or any other convenient pathname).
-
- SFMultiGet2 (AND SFPMultiGet2) REPLY RECORD
-
- SFMultiGet2 and SFPMultiGet2 in System 5.0.4 and earlier accidentally validate
- the multi-file reply record as if it were a regular new-style reply record (as
- for SFGetFile2, for example). The validation is a check that the words at
- offsets $08 and $0E in the record are not $0002 (these are nameRefDesc and
- pathRefDesc in a new-style reply record).
-
- To ensure that Standard File does not erroneously reject your multi-file reply
- record (and return error $1704), you may include ten bytes of $00 following
- the six-byte record.
-
- Further Reference
- _____________________________________________________________________________
-
- o Apple IIgs Toolbox Reference, Volumes 2 & 3
-